Section 14 Setting Subscription Options for Subscribers Using Email
The syntax is similar to the subscriber's method of reviewing his options, except that the list owner must specify for whom the options are being checked.
will return option listings for subscribers such as JIMJ@UBVM, JOHN@UBVMS.CC.BUFFALO.EDU, etc. This can be handy if you are searching the list for someone whose subscription address differs from the address you are given in an error report (see the examples, above, in "Dealing with bounced mail").
Using the WITH qualifier, you can also query a list for users who have a specific option set. For instance, you might want to know which users are set to
NOMAIL. Send the command
Setting this option to Mail indicates that the subscriber will receive mail from the list.
NOMail is the complementary command that stops mail but leaves the user subscribed to the list. (
NOMail is often a good compromise for users who are leaving the office for vacation or on extended business trips, and who don't want a full mailbox on their return.) The format of the messages received is controlled by the
DIGEST/INDEX/NODIGEST/NOINDEX options (see the following sections).
The MAIL/NOMAIL option is isolated from
DIGEST/INDEX. The
MAIL/NOMAIL option controls whether messages should be delivered, and the
DIGEST/INDEX/NODIGEST/NOINDEX option controls the format in which messages should be delivered. Thus, switching to
NOMAIL and back to
MAIL now preserves the digest/index/normal delivery setting. To provide as much compatibility with the old syntax as possible, the four options operate as follows:
|
•
|
DIGEST – Enable digest delivery mode (which negates INDEX), enable mail delivery.
|
|
•
|
INDEX – Enable index delivery mode (which negates DIGEST), enable mail delivery.
|
|
•
|
NOMAIL – Disable mail delivery.
|
|
•
|
MAIL – Restore mail delivery. Note that If mail delivery was already enabled, the MAIL option negates INDEX/DIGEST. Thus, a user going from NOMAIL to MAIL will keep his previous delivery options, whereas a user going from DIGEST or INDEX to MAIL will in fact deactivate index/digest mode.
|
The command SET listname MAIL sent by a user who is set to
DIGEST but not also set to NOMAIL will cause the user to be set to
NODIGEST (the behavior is identical for users set to
INDEX but not to
NOMAIL).
SET listname MAIL sent by users set to
DIGEST/NOMAIL or
INDEX/NOMAIL will simply remove the
NOMAIL setting and leave the user set to
DIGEST or
INDEX as the case may be.
Note: In extreme cases, subscribers using the
DIGEST option may receive more than one digest per cycle if the digest limit is reached before the end of the cycle.
Toggles MIME functions on and off. Currently this is only useful if the user has a mail client that supports MIME digests. Users who send their
SUBSCRIBE command using a MIME-compliant agent will have this option set automatically unless "
Default-Options= NOMIME" is specified for the list.
Causes the subscriber to receive one posting per digest cycle containing only an index of subject topics for all messages during that cycle. See the section on
DIGEST (above) for further information.
These three command words control the level of acknowledgment the subscriber receives when posting to the list.
ACK causes LISTSERV to send a short confirmation message to the subscriber when the post has been received and distributed.
NOACK disables the confirmation feature for the subscriber (although BITNET subscribers will receive a short interactive message on their terminal). For BITNET subscribers,
MSGack provides the same information as
ACK via interactive messages.
By specifying one of the following command words, the subscriber can control the amount of mail header information prepended to list mail. The syntax is
SET listname headertype, where
headertype is one of the following:
|
•
|
FULLhdr – "Full" mail headers (default)
|
|
•
|
SUBJecthdr – "Full" RFC822 mail headers (like the default), except that LISTSERV adds the list's default subject tag to the subject line of mail coming from the list. To turn this off, simply set another mail header option.
|
|
•
|
SHORThdr – Short headers (formerly SHORTBSMTP)
|
|
•
|
DUALhdr – Dual headers, useful with older PC or Mac mail programs
|
|
•
|
FULL822 – "Full" RFC822 mail headers
|
Note: Do not use
FULL822 or
SHORT822 unless debugging specific problems or unless directed by L-Soft. Use of these options can seriously slow performance as they force LISTSERV to generate a separate "envelope" for each user so set.
FULL822 and
SHORT822 are obsolete but remain available for compatibility with certain older mailers.
Documented Restriction: The use of the
SHORTHDR or
DUALHDR options will break messages that depend on MIME encoding, because these options strip the RFC822 headers that identify the message as a MIME message.
SHORTHDR and
DUALHDR were designed for the non-MIME mail clients which prevailed in LISTSERV's early history. As most mail clients today support MIME, the use of these options is now deprecated.
The SUBJECTHDR (minimum abbreviation:
SUBJ) header option is provided for users who want to see a "tag" in the subject line of their incoming list mail that indicates where the mail is coming from (e.g., to activate a filter in their mail program to drop the message into a specified notebook). If you have
SHORT headers (or any other header option) set, setting your option to
SUBJecthdr will automatically change you to
FULLHdr, as subject tags require full headers. Also, subject tags are not generated for messages sent without a RFC822 "Subject:" header.
The DUALHDR (minimum abbreviation:
DUAL) header option is provided to help in certain debugging cases. Dual headers are regular short (
SHORThdr) headers followed by a second header inside the message body. This second header shows what list the message is coming from ('Sender:'), the name and address of the person who posted it ('Poster:'), the poster's organization, if present, and the message subject. The date is not shown as it will generally be displayed in the "normal" set of headers. This setting, as noted, is deprecated, and should only be used for debugging.
Generally, users will be best served by the FULL or
SUBJ header options. FULL is the default.
To do this, use the SUBJecthdr personal option as explained in the previous section. To set this option by default for new subscribers, include it in the
Default-Options= keyword setting for your list (see Section 14.4
Setting Original Default Options with the Default-Options= Keyword). To set it for existing subscribers, use the
SET command.
Occasionally, a subscriber may not want his presence to be known to someone else making a casual
REView of the list. Subscribers may choose to "hide" their subscription from the
REView command by using the
CONCEAL command. Conversely, a subscriber may choose to remove this restriction by issuing the
NOCONCEAL command.
Note: The list owner can always obtain a list of all subscribers, both concealed and unconcealed, by issuing the
GET listname (NOLock) command, or by issuing a
QUERY listname WITH CONCEAL FOR *@* command. The list owner may also restrict the use of the REVIEW command to list owners.
This option controls whether or not the subscriber will get a copy of his or her own posts back from the list after they are processed. Generally, if a subscriber's mail program is configured to file copies of the subscriber's outgoing mail, or if the subscriber has one of the acknowledgment options (
ACK/MSGack) enabled, this option should be set to
NOREPro. If, on the other hand, the subscriber is set to
NOACK and doesn't keep a copy of outgoing mail, this option should probably be set to
REPro. (It should be noted that some mail services, such as GMail, will not deliver the REPro copy sent by LISTSERV to their users, and this option is therefore not useful for those users.)
If list topics are enabled, this option allows the subscriber to specify which topics he or she will receive. The syntax of a SET TOPICS statement is significantly different from that of the other options. See Section 15.7
Using List Topics for more information on this syntax.
A subscriber set to NOPOST may not post to the list.
NOPOST gives the individual list owner the ability to serve out abusive or obnoxious posters without having to add such users to the list's "
Filter=" setting. Subscribers set to
NOPOST will still receive list mail – they just won't be able to post mail to the list.
Note: For peered lists,
NOPOST must be set globally or a user can bypass the setting by simply posting to another peer. Thus, you must add the user manually to the other peers and then set the user to
NOMAIL as well as
NOPOST on the peers.
Setting NOPOST for a user cancels any previous
EDITOR or
REVIEW setting for that user.
Note: List editors who are set to
NOPOST will be able to approve messages but will then be told they cannot post to the list. The
NOPOST subscriber option does override any
Editor= or
Moderator= definition in the list header, so be sure that your editors and moderators are set to
POST.
A subscriber set to EDITOR on an edited/moderated list may post directly to the list without a moderator's intervention. It is virtually identical to adding the subscriber's address to the "
Editor=" keyword, but easier to manage. The only difference between the
EDITOR option and the "
Editor=" keyword, other than not being visible in the list header, is that the "
Editor=" keyword also defines a (seldom used) access level class that can then be used in keywords such as "
Review=". Thus, one could have a list with "
Review= Editor", indicating that only the users listed in the "
Editor=" keyword are allowed to review the list. The EDITOR option does not confer this privilege.
Note: The
EDITOR option is only meaningful on moderated lists.
Setting EDITOR for a user cancels any previous NOPOST or REVIEW setting for that user.
When a subscriber is set to REVIEW, all postings from that subscriber are forwarded to the list editor or list owner for approval. Approval for these postings is always via the OK mechanism – there is no need to forward the posting to the list, simply reply to the approval confirmation with "OK".
Note that if a list is unmoderated, it is still possible to direct REVIEW postings to a specific person by adding an "
Editor=" or "
Moderator=" keyword to the list header.
Setting REVIEW for a user cancels any previous
NOPOST or
EDITOR setting for that user.
Enables or disables subscription renewal confirmation on an individual subscriber basis. Setting a subscription to
NORENEW is particularly useful for exempting list owners, redistribution lists, and other subscriptions which should not or must not receive the confirmation request message from the renewal process.
The list owner may specify original defaults for many subscriber options by using the "
Default-Options=" keyword. This keyword takes regular
SET options as its parameters. Examples include:
You may have more than one "Default-Options=" line in your header, as needed.
Notes: Any default topics are set with the "Default-Topics=" keyword. See the
List Keyword Reference document for details on this keyword.
Your existing subscribers are not affected by any change to the
Default-Options= keyword. This keyword sets initial options only for people who subscribe after it is defined. If you want to update your existing subscribers to the
Default-Options settings, you must use the
SET command with a wildcard (i.e.,
FOR *@*) to do so.
The Misc-Options= keyword is a catch-all for certain behavior-modifying options that are not otherwise covered by other, more specific keyword settings. Currently the only options available are as follows:
The actual function of this setting is to remove the attachment that contains the HTML mail from the message. It does not remove HTML tags from plain text messages. This means that setting this option will not suppress HTML in messages sent from older mail clients which may not send HTML messages as a MIME attachment plus a plain text alternative).
The DROP_BAD_MAIL_ORIGIN option can be added to Misc-Options= in order to reject mail messages that have (in most cases) a malformed RFC822 mail header, for instance, no ‘From:’, or three different ‘From:’, etc.
In general such messages are spam, and it may be appropriate to reject them at the list level by setting this option in the list header (or site-wide, by setting it in DEFAULT_MISC_OPTIONS).
Notes: Notes: Setting this option may cause idiosyncratic issues with the way Gmail presents the mail in its indexes. The REPRO copy of the mail will show up in both the Sent folder and the Inbox folder, as part of a single thread. This is cosmetic only; the links are to the same message, and if one is marked as read, the other will also be marked as read.
Additionally, if the Gmail user’s subscription is set to SUBJECTHDR, the Gmail interface will not display “[LISTNAME]” as part of the subject of the REPRO copy. This could lead to the erroneous conclusion that the original message and the REPRO copy are duplicates, except for small differences in the timestamp. The only useful way to show the difference is to use Gmail’s “Show original” feature to inspect the headers thus revealed.
Add subject tags to IETF headers (that is, for users who are set to the IETFHDR personal option). However, as this can be considered a violation of the standard for IETF-style headers, it can be prevented site-wide by the site administrator if desired.
Adding “Misc-Options= IETFHDR_SUBJECT_TAG“ to the list header causes the IETFHDR option to always include subject tags. This is a per-list setting; in other words, either all subscribers to a list who are set to the IETFHDR option get the subject-tag, or no. The design consideration is that, at present, it is prohibitively expensive to switch the existing header types into flags as the number of combinations grows significantly.
When set in a list header, "Misc-Options= IGNORE_EMAIL_CASE" causes the ADD command to ignore the case of the "local part" of list subscriber entries (that is, the part of the address that is to the left of the "@" sign). Although most modern mail clients are configured to ignore the case of the local-part, this behavior technically violates RFC821 which states that local-parts are considered case-sensitive.
If an entry whose "local part" differs only in case is found in the list during an ADD operation (for instance, JOE@EXAMPLE.COM vs. joe@EXAMPLE.COM), that entry will be assumed to be the entry that was sought, and the address field will be updated to the new case (that is, "JOE@" will be changed to "joe@"). No other change will be made to the entry unless there is a change in the name field, in which case the name field will also be updated.
If there is no change in the address field associated with the entry, no change will be made to the entry (again, unless the name field changes, in which case the entry will be updated).
When a list is set to "Misc-Options= RESPECT_EMAIL_CASE", this tells LISTSERV to operate per RFC821 and treat address fields with differently-cased local parts as different addresses. The option is provided as an override to the site-level IGNORE_EMAIL_CASE configuration variable and does not need to be set to preserve the default unless the site setting has been changed to make IGNORE_EMAIL_CASE the default.
The KEEP_DKIM_SIGNATURE option is experimental and not meant for general use. As DomainKeys is specified today, signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so LISTSERV removes them by default to avoid triggering alerts for subscribers on systems that have implemented the client side of DomainKeys. That being said, LISTSERV has DKIM support built-in and can be configured at the server level to sign messages to the DKIM standard. See the section on DKIM in the
Advanced Topics Manual for LISTSERV for more information.
Tells LISTSERV to keep Microsoft Exchange attachments in postings (the default is to remove them). Note that this affects "application/ms-tnef" attachments only-- LISTSERV does not currently strip WINMAIL.DAT attachments.
When specified, NEW_MESSAGE_ID causes LISTSERV to generate a new RFC822 Message-ID: field for outbound messages. This solves a problem with email providers that bounce messages with duplicate Message-ID: fields. Specifically, it solves the problem experienced by Gmail subscribers who are set to the REPRO option, and currently do not receive the copy of their own mail sent to them by the server after it is processed.
Notes: Setting this option may cause idiosyncratic issues with the way Gmail presents the mail in its indexes. The REPRO copy of the mail will show up in both the Sent folder and the Inbox folder, as part of a single thread. This is cosmetic only; the links are to the same message, and if one is marked as read, the other will also be marked as read.
Additionally, if the Gmail user’s subscription is set to SUBJECTHDR, the Gmail interface will not display “[LISTNAME]” as part of the subject of the REPRO copy. This could lead to the erroneous conclusion that the original message and the REPRO copy are duplicates, except for small differences in the timestamp. The only useful way to show the difference is to use Gmail’s “Show original” feature to inspect the headers thus revealed.
Important: Systematically changing message IDs does not follow relevant Internet standards for mail, and could conceivably promote mailing loops. Consider carefully whether or not the benefits of viewing REPRO mail in Gmail outweigh the potential problems engendered by changing message IDs before adding this setting to your list(s).
"Misc-Options= NO_DKIM_SIGNATURE" is available at the list level to override LISTSERV's default Domain Keys Identified Mail (DKIM) message signing if desired.
and this can also be specified in the site-wide DEFAULT_MISC_OPTIONS variable. When RFC2369 support is disabled, RFC2369 tags on incoming messages are neither added nor removed.
Use this option to disable spam scans for a particular list and its associated xxx-request address. (This is only useful if the LISTSERV maintainer has enabled spam-scanning via the SPAM_EXIT feature.)
It is possible for each list posting to have a sequence number attributed to it, which can be seen by subscribers who are set to the SUBJECTHDR personal option. This feature is enabled by adding "
Misc-Options= SUBJECTHDR_SEQUENCE" to the list header. Site administrators can enable it server-wide by adding the value
SUBJECTHDR_SEQUENCE to DEFAULT_MISC_OPTIONS in the site configuration. The format of the new subject tag is
"Subject-Tag=" is still used to change the first item. In order to allow server administrators to set a server-wide default for the new feature, it was not possible to implement the sequence number feature as an extension to "Subject-Tag=".
Note: Both the new [listname - number] and the traditional [listname] tags are removed from the subject on incoming messages. This happens whether or not the option is set, because people might be replying to old messages before the option was changed.
LISTSERV tries very hard never to skip a sequence number. The only plausible scenario in which this could ever happen would be when the MTA (not LISTSERV) fails to deliver the message. However, there are several cases where a sequence number will be reused:
While this option is useful to protect the privacy of list moderators in cases where (for instance) a list is moderated selectively in order to address social problems among the members, suppressing the “Approved-By:” header can make it harder (but not impossible, since the LISTSERV maintainer can determine this from the LISTSERV console logs) to ascertain which moderator on a multi-moderator list actually approved a given message. Of course, on some lists, that may be considered a feature rather than a bug. Your mileage (as they say) may vary.
